Web Security Headers: En praktisk implementeringsguide

I nutidens digitale landskab er websikkerhed altafgørende. Hjemmesider er konstant mål for forskellige angreb, herunder cross-site scripting (XSS), clickjacking og datainjektion. Implementering af web security headers er et afgørende skridt i at afbøde disse risici og beskytte dine brugere og data. Denne guide giver en omfattende oversigt over centrale security headers og hvordan man implementerer dem effektivt.

Hvad er Web Security Headers?

Web security headers er HTTP-svarhoveder, der instruerer webbrowsere om, hvordan de skal opføre sig, når de håndterer dit websites indhold. De fungerer som et sæt regler, der fortæller browseren, hvilke handlinger der er tilladte, og hvilke der er forbudte. Ved at indstille disse headers korrekt kan du markant reducere angrebsfladen på dit website og forbedre dets samlede sikkerhedsposition. Security headers forbedrer eksisterende sikkerhedsforanstaltninger og giver et ekstra lag af forsvar mod almindelige websårbarheder.

Hvorfor er Security Headers vigtige?

• Afbødning af almindelige angreb: Security headers kan effektivt blokere eller afbøde mange almindelige webangreb, såsom XSS, clickjacking og MIME-sniffing-angreb.
• Forbedring af brugerens privatliv: Nogle headers kan hjælpe med at beskytte brugerens privatliv ved at kontrollere henvisningsoplysninger og begrænse adgangen til browserfunktioner.
• Forbedring af websitets sikkerhedsposition: Implementering af security headers viser en forpligtelse til sikkerhed og kan forbedre dit websites omdømme.
• Overholdelseskrav: Mange sikkerhedsstandarder og -regler, såsom GDPR og PCI DSS, kræver eller anbefaler brugen af security headers.

Vigtige Security Headers og deres implementering

Her er en oversigt over de vigtigste security headers og hvordan man implementerer dem:

1. Content-Security-Policy (CSP)

Content-Security-Policy (CSP) headeren er en af de mest kraftfulde security headers. Den giver dig mulighed for at kontrollere de kilder, hvorfra browseren må indlæse ressourcer, såsom scripts, stylesheets, billeder og skrifttyper. Dette hjælper med at forhindre XSS-angreb ved at forhindre browseren i at udføre ondsindet kode, der er injiceret på dit website.

Implementering:

CSP-headeren sættes med `Content-Security-Policy`-direktivet. Værdien er en liste af direktiver, hvor hvert direktiv specificerer de tilladte kilder for en bestemt type ressource.

Eksempel:

            Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://example.com; img-src 'self' data:; font-src 'self'; connect-src 'self' wss://example.com;

            

              
                Copy
              
            
          

Forklaring:

• `default-src 'self'`: Specificerer, at alle ressourcer skal indlæses fra samme oprindelse som dokumentet, medmindre det er specificeret anderledes af et mere specifikt direktiv.
• `script-src 'self' https://example.com`: Tillader, at scripts indlæses fra samme oprindelse og fra `https://example.com`.
• `style-src 'self' https://example.com`: Tillader, at stylesheets indlæses fra samme oprindelse og fra `https://example.com`.
• `img-src 'self' data:`: Tillader, at billeder indlæses fra samme oprindelse og fra data-URI'er (indlejrede billeder).
• `font-src 'self'`: Tillader, at skrifttyper indlæses fra samme oprindelse.
• `connect-src 'self' wss://example.com`: Tillader, at forbindelser (f.eks. AJAX, WebSockets) oprettes til samme oprindelse og til `wss://example.com`.

Vigtige CSP-direktiver:

• `default-src`: Et fallback-direktiv, der gælder for alle ressourcetyper, hvis der ikke er specificeret noget andet direktiv.
• `script-src`: Styrer kilderne for JavaScript.
• `style-src`: Styrer kilderne for stylesheets.
• `img-src`: Styrer kilderne for billeder.
• `font-src`: Styrer kilderne for skrifttyper.
• `media-src`: Styrer kilderne for lyd og video.
• `object-src`: Styrer kilderne for plugins som Flash.
• `frame-src`: Styrer kilderne for frames og iframes.
• `connect-src`: Styrer de URL'er, som et script kan oprette forbindelse til (f.eks. AJAX, WebSockets).
• `base-uri`: Begrænser de URL'er, der kan bruges i et dokuments <base>-element.
• `form-action`: Begrænser de URL'er, som formularer kan sendes til.

CSP Report-Only-tilstand:

Før du håndhæver en CSP-politik, anbefales det at bruge report-only-tilstand. Dette giver dig mulighed for at overvåge politikkens indvirkning uden at blokere nogen ressourcer. Headeren `Content-Security-Policy-Report-Only` bruges til dette formål.

Eksempel:

            Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' https://example.com; report-uri /csp-report-endpoint;

            

              
                Copy
              
            
          

I dette eksempel vil eventuelle overtrædelser af CSP-politikken blive rapporteret til URL'en `/csp-report-endpoint`. Du skal opsætte et server-side endepunkt til at modtage og analysere disse rapporter. Værktøjer som Sentry og Google CSP Evaluator kan hjælpe med oprettelse af og rapportering for CSP-politikker.

2. X-Frame-Options

X-Frame-Options-headeren bruges til at beskytte mod clickjacking-angreb. Clickjacking opstår, når en angriber narrer en bruger til at klikke på noget andet end det, de opfatter, ofte ved at indlejre et legitimt website i en ondsindet iframe.

Implementering:

X-Frame-Options-headeren kan have tre mulige værdier:

• `DENY`: Forhindrer siden i at blive vist i en frame, uanset oprindelsen.
• `SAMEORIGIN`: Tillader, at siden vises i en frame, kun hvis framens oprindelse er den samme som sidens oprindelse.
• `ALLOW-FROM uri`: (Forældet og ikke anbefalet) Tillader, at siden vises i en frame, kun hvis framens oprindelse matcher den specificerede URI.

Eksempler:

            X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN

            

              
                Copy
              
            
          

For de fleste websites er `SAMEORIGIN`-indstillingen den mest passende. Hvis dit website aldrig skal indlejres i en frame, skal du bruge `DENY`. `ALLOW-FROM`-indstillingen frarådes generelt på grund af problemer med browserkompatibilitet.

Vigtigt: Overvej at bruge CSP's `frame-ancestors`-direktiv i stedet for `X-Frame-Options` for bedre kontrol og kompatibilitet, da `X-Frame-Options` betragtes som forældet. `frame-ancestors` giver dig mulighed for at specificere en liste over oprindelser, der har tilladelse til at indlejre ressourcen.

3. Strict-Transport-Security (HSTS)

Strict-Transport-Security (HSTS)-headeren tvinger browsere til kun at kommunikere med dit website via HTTPS. Dette forhindrer man-in-the-middle-angreb, hvor en angriber kan opsnappe usikker HTTP-trafik og omdirigere brugere til et ondsindet website.

Implementering:

HSTS-headeren specificerer `max-age`-direktivet, som angiver det antal sekunder, browseren skal huske kun at tilgå sitet via HTTPS. Du kan også inkludere `includeSubDomains`-direktivet for at anvende HSTS-politikken på alle underdomæner.

Eksempel:

            Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

            

              
                Copy
              
            
          

Forklaring:

• `max-age=31536000`: Specificerer, at browseren skal huske kun at tilgå sitet via HTTPS i et år (31.536.000 sekunder). En længere `max-age` anbefales generelt til produktionsmiljøer.
• `includeSubDomains`: Anvender HSTS-politikken på alle underdomæner af websitet.
• `preload`: Angiver, at du gerne vil have dit domæne forudindlæst i browserens HSTS-preload-liste. Dette er et valgfrit direktiv, der kræver, at du indsender dit domæne til HSTS-preload-listen, der vedligeholdes af Google. Forudindlæsning sikrer, at brugere, der opretter forbindelse til dit site for første gang, vil bruge HTTPS.

Vigtigt: Før du aktiverer HSTS, skal du sikre dig, at hele dit website og alle dets underdomæner er tilgængelige via HTTPS. Hvis du ikke gør det, kan det resultere i, at brugere ikke kan tilgå dit website.

4. X-Content-Type-Options

X-Content-Type-Options-headeren forhindrer MIME-sniffing-angreb. MIME-sniffing er en teknik, hvor browseren forsøger at gætte indholdstypen af en ressource, selvom serveren har specificeret en anden indholdstype. Dette kan føre til sikkerhedssårbarheder, hvis browseren fejlagtigt fortolker en fil som eksekverbar kode.

Implementering:

X-Content-Type-Options-headeren har kun én mulig værdi: `nosniff`.

Eksempel:

            X-Content-Type-Options: nosniff

            

              
                Copy
              
            
          

Denne header fortæller browseren, at den ikke skal forsøge at gætte indholdstypen af en ressource og udelukkende skal stole på `Content-Type`-headeren, der er specificeret af serveren.

5. Referrer-Policy

Referrer-Policy-headeren kontrollerer, hvor meget henvisningsinformation (URL'en på den forrige side) der sendes til andre websites, når en bruger navigerer væk fra dit website. Dette kan hjælpe med at beskytte brugerens privatliv ved at forhindre, at følsomme oplysninger lækkes til tredjeparts-sites.

Implementering:

Referrer-Policy-headeren kan have flere mulige værdier, hvor hver specificerer et forskelligt niveau af henvisningsinformation, der skal sendes:

• `no-referrer`: Send aldrig Referer-headeren.
• `no-referrer-when-downgrade`: Send ikke Referer-headeren, når der navigeres fra HTTPS til HTTP.
• `origin`: Send kun dokumentets oprindelse (f.eks. `https://example.com`).
• `origin-when-cross-origin`: Send oprindelsen, når der navigeres til en anden oprindelse, og send den fulde URL, når der navigeres til samme oprindelse.
• `same-origin`: Send Referer-headeren for anmodninger til samme oprindelse, men ikke for anmodninger på tværs af oprindelser.
• `strict-origin`: Send kun oprindelsen, når protokolsikkerhedsniveauet forbliver det samme (HTTPS til HTTPS), men send den ikke til en mindre sikker destination (HTTPS til HTTP).
• `strict-origin-when-cross-origin`: Send oprindelsen, når der navigeres til en anden oprindelse, men kun hvis protokolsikkerhedsniveauet forbliver det samme (HTTPS til HTTPS). Send den fulde URL, når der navigeres til samme oprindelse.
• `unsafe-url`: (Ikke anbefalet) Send altid den fulde URL som Referer-header. Dette er den mindst sikre mulighed.

Eksempler:

            Referrer-Policy: strict-origin-when-cross-origin
Referrer-Policy: no-referrer

            

              
                Copy
              
            
          

`strict-origin-when-cross-origin`-politikken er ofte en god balance mellem sikkerhed og funktionalitet. Den beskytter brugerens privatliv ved ikke at sende den fulde URL til forskellige oprindelser, samtidig med at den giver websites mulighed for at spore grundlæggende henvisningsinformation.

6. Permissions-Policy (tidligere Feature-Policy)

Permissions-Policy-headeren (tidligere kendt som Feature-Policy) giver dig mulighed for at kontrollere, hvilke browserfunktioner (f.eks. kamera, mikrofon, geolokation), der må bruges af dit website og af indlejrede iframes. Dette kan hjælpe med at forhindre ondsindet kode i at få adgang til følsomme browserfunktioner uden brugerens udtrykkelige samtykke.

Implementering:

Permissions-Policy-headeren specificerer en liste af direktiver, hvor hvert direktiv styrer adgangen til en specifik browserfunktion. Hvert direktiv består af et funktionsnavn og en liste over tilladte oprindelser.

Eksempel:

            Permissions-Policy: geolocation 'self' https://example.com; camera 'none'; microphone (self)

            

              
                Copy
              
            
          

Forklaring:

• `geolocation 'self' https://example.com`: Tillader websitet og `https://example.com` at bruge geolokationsfunktionen.
• `camera 'none'`: Deaktiverer kamerafunktionen for websitet og alle indlejrede iframes.
• `microphone (self)`: Tillader websitet at bruge mikrofonfunktionen. Bemærk den forskellige syntaks med parenteser for individuelle oprindelser.

Almindelige Permissions-Policy-funktioner:

• `geolocation`: Styrer adgang til geolokations-API'en.
• `camera`: Styrer adgang til kameraet.
• `microphone`: Styrer adgang til mikrofonen.
• `autoplay`: Styrer, om medier kan afspilles automatisk.
• `fullscreen`: Styrer, om websitet kan gå i fuldskærmstilstand.
• `accelerometer`: Styrer adgang til accelerometeret.
• `gyroscope`: Styrer adgang til gyroskopet.
• `magnetometer`: Styrer adgang til magnetometeret.
• `speaker`: Styrer adgang til højttaleren.
• `vibrate`: Styrer adgang til vibrate-API'en.
• `payment`: Styrer adgang til Payment Request-API'en.

7. Andre Security Headers

Mens de ovenfor diskuterede headers er de mest almindeligt anvendte og vigtige, kan andre security headers yde yderligere beskyttelse:

• X-Permitted-Cross-Domain-Policies: Denne header styrer, hvordan Adobe Flash Player og andre plugins håndterer anmodninger på tværs af domæner. Den anbefalede værdi er normalt `none`.
• Clear-Site-Data: Giver et website mulighed for at rydde browserdata (cookies, lager, cache), når brugeren forlader sitet. Dette kan være nyttigt for privatlivsfølsomme applikationer.
• Expect-CT: Aktiverer Certificate Transparency, som hjælper med at forhindre brugen af svigagtigt udstedte SSL-certifikater.

Implementering af Security Headers

Security headers kan implementeres på forskellige måder, afhængigt af din webserver eller content delivery network (CDN).

1. Webserverkonfiguration

Du kan konfigurere din webserver (f.eks. Apache, Nginx) til at tilføje security headers til HTTP-svaret. Dette er ofte den mest direkte og effektive måde at implementere security headers på.

Apache:

Du kan bruge `Header`-direktivet i din Apache-konfigurationsfil (`.htaccess` eller `httpd.conf`) til at indstille security headers.

Eksempel:

            Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://example.com;"
Header set X-Frame-Options "SAMEORIGIN"
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
Header set X-Content-Type-Options "nosniff"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header set Permissions-Policy "geolocation 'self'"

            

              
                Copy
              
            
          

Nginx:

Du kan bruge `add_header`-direktivet i din Nginx-konfigurationsfil (`nginx.conf`) til at indstille security headers.

Eksempel:

            add_header Content-Security-Policy "default_src 'self'; script-src 'self' https://example.com;";
add_header X-Frame-Options "SAMEORIGIN";
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
add_header X-Content-Type-Options "nosniff";
add_header Referrer-Policy "strict-origin-when-cross-origin";
add_header Permissions-Policy "geolocation 'self';";

            

              
                Copy
              
            
          

2. Content Delivery Network (CDN)

Mange CDN'er, såsom Cloudflare, Akamai og Fastly, tilbyder funktioner til at konfigurere security headers. Dette kan være en bekvem måde at implementere security headers på, især hvis du allerede bruger et CDN.

Eksempel (Cloudflare):

I Cloudflare kan du konfigurere security headers ved hjælp af funktionerne "Rules" eller "Transform Rules". Du kan definere regler for at tilføje, ændre eller fjerne HTTP-headers baseret på forskellige kriterier, såsom URL eller anmodningstype.

3. Kode på serversiden

Du kan også indstille security headers i din server-side-kode (f.eks. ved hjælp af PHP, Python, Node.js). Denne tilgang giver dig mere fleksibilitet til dynamisk at indstille headers baseret på anmodningen eller brugerkonteksten.

Eksempel (Node.js med Express):

            const express = require('express');
const app = express();

app.use((req, res, next) => {
  res.setHeader('Content-Security-Policy', "default-src 'self'; script-src 'self' https://example.com;");
  res.setHeader('X-Frame-Options', 'SAMEORIGIN');
  res.setHeader('Strict-Transport-Security', 'max-age=31536000; includeSubDomains; preload');
  res.setHeader('X-Content-Type-Options', 'nosniff');
  res.setHeader('Referrer-Policy', 'strict-origin-when-cross-origin');
  res.setHeader('Permissions-Policy', "geolocation 'self'");
  next();
});

app.get('/', (req, res) => {
  res.send('Hello World!');
});

app.listen(3000, () => {
  console.log('Server listening on port 3000');
});

            

              
                Copy
              
            
          

Test og validering

Efter implementering af security headers er det afgørende at teste og validere, at de fungerer korrekt. Flere onlineværktøjer kan hjælpe dig med dette:

• SecurityHeaders.com: Dette website scanner dit website og giver en rapport om de implementerede security headers og eventuelle problemer.
• Mozilla Observatory: Dette onlineværktøj udfører en række tests på dit website, herunder security headers, og giver en detaljeret rapport med anbefalinger til forbedringer.
• Browser Developer Tools: Du kan bruge din browsers udviklerværktøjer (f.eks. Chrome DevTools, Firefox Developer Tools) til at inspicere HTTP-svarhovederne og verificere, at security headers er til stede og har de korrekte værdier.

Eksempel med Chrome DevTools:

1. Åbn Chrome DevTools (højreklik på siden og vælg "Inspicer").
2. Gå til fanen "Network".
3. Genindlæs siden.
4. Vælg hoveddokumentanmodningen (normalt den første anmodning på listen).
5. Gå til fanen "Headers".
6. Rul ned til sektionen "Response Headers" for at se security headers.

Almindelige fejl og bedste praksis

Her er nogle almindelige fejl, man skal undgå, når man implementerer security headers:

• Ikke at teste grundigt: Test altid dine security headers i et testmiljø, før du implementerer dem i produktion.
• Brug af for tilladende CSP-politikker: Start med en restriktiv CSP-politik og løsn den gradvist efter behov.
• Glemme at inkludere underdomæner i HSTS: Hvis du vil beskytte alle underdomæner, skal du sørge for at inkludere `includeSubDomains`-direktivet i HSTS-headeren.
• Brug af forældede headers: Undgå at bruge forældede headers som `X-Download-Options` og `X-Powered-By`.
• Ikke at overvåge overtrædelser af security headers: Opsæt et system til at overvåge CSP report-only-overtrædelser for at identificere og løse eventuelle problemer.

Bedste praksis:

• Start med en stærk baseline: Implementer mindst de grundlæggende security headers (CSP, X-Frame-Options, HSTS, X-Content-Type-Options, Referrer-Policy, Permissions-Policy).
• Brug en Content Security Policy (CSP): Content Security Policy hjælper med at forhindre XSS-angreb ved at definere de oprindelser, hvorfra browseren skal have tillid til at indlæse ressourcer.
• Gennemgå og opdater jævnligt dine security headers: Efterhånden som nye sårbarheder opdages og browserteknologier udvikler sig, er det vigtigt at gennemgå og opdatere dine security headers i overensstemmelse hermed.
• Brug et CDN: CDN'er kan forenkle implementeringen og administrationen af security headers.
• Automatiser implementeringen af security headers: Brug automatiseringsværktøjer til at sikre, at security headers implementeres konsekvent på tværs af alle miljøer.
• Hold dig informeret: Hold dig opdateret om de seneste sikkerhedstrusler og bedste praksis ved at følge sikkerhedsblogs, deltage i sikkerhedskonferencer og deltage i sikkerhedsfællesskaber. OWASP (Open Web Application Security Project) er en fantastisk ressource for information om websikkerhed.

Konklusion

Implementering af web security headers er et essentielt skridt i at beskytte dit website og dine brugere mod almindelige angreb. Ved at forstå formålet med hver header og følge de bedste praksis, der er beskrevet i denne guide, kan du markant forbedre dit websites sikkerhedsposition og opbygge tillid hos dine brugere. Husk at teste og overvåge dine security headers regelmæssigt for at sikre, at de fungerer effektivt, og for at tilpasse dig til skiftende sikkerhedstrusler. At investere tid og kræfter i at implementere security headers vil betale sig i det lange løb ved at beskytte dit website og dine brugere mod skade. Som en sidste bemærkning kan du overveje at konsultere en sikkerhedsekspert eller bruge en sikkerhedsrevisionstjeneste til at vurdere dit websites sikkerhed og identificere eventuelle sårbarheder.